Developers Should Carry the Banner of Software Standards

By: Peter Coffee

Software standards used to be developed by programmers, for programmers, as tools for ensuring interoperability and achieving greater leverage for developers' skills.

Increasingly, though, development teams find their efforts affected by standards that respond to external forces, such as corporate governance regulators, consumer protection activists, civil rights advocates, and other stakeholders and scrutineers.

Development teams must expand the sweep of their radar to become aware of new strictures and to allocate time, invest in training and incorporate appropriate conformance tools into their work.

Software development is coming late to the standards party. Industry and commerce take place in environments pervaded by all manner of standards.

Included by reference in contracts, enforced in many situations with the power of criminal law and taken for granted by customers in any reputable place of business, it's these detailed public definitions of acceptable practice that make it possible to exchange complex products and services—without making every customer individually responsible for expensive and redundant inspections and certifications.

Both developers and users suffer from the present limited scope and power of comparable software standards. They grapple with mutual hostility and incur unnecessary costs due to lack of mutually understood obligations—those of the developer to offer a reliable product and those of the buyer to define what purchased software needs to do.

Software as product

If a piece of pipe is labeled as conforming to a particular grade of material or an electrical component is labeled as being safe for use at a certain voltage, these are objective statements. Software function and performance measurements, in contrast, are notoriously difficult to reproduce even in a single artificial test environment, let alone in a way that's meaningful to typical users in real-world situations.

Finding it difficult to certify software to the kind of standard associated with an Underwriters Laboratories Inc. tag or an ASTM (American Society for Testing and Materials) International marking, software sellers have notoriously taken refuge in contract law to shield themselves from buyer expectations. Software often is surrounded by lawyerly EULAs (end-user license agreements) that have become infamous for their evasions of responsibility.

Some such EULA clauses are eyebrow-raising but pose little actual impediment to everyday use. An oft-quoted passage from the Java licensing agreement, for example, demands, "You acknowledge that Licensed Software is not designed or intended for use in the design, construction, operation or maintenance of any nuclear facility."

Most software users would probably find this a reasonable warning: Anyone buying software for a task as complex and risky as managing a nuclear power plant should accept the burden of verifying the software's adequacy to that task or surrounding an external provider's general-purpose software with task-specific safety systems.

Users may be less comfortable with the sweeping language—assuming they've ever even read it—of Microsoft's Windows XP Home Edition license.

In very small part this states (with capitals from the original) that "Microsoft and its suppliers provide the Software ... AS IS AND WITH ALL FAULTS, and hereby disclaim all other warranties and conditions, whether express, implied or statutory, including, but not limited to, any (if any) implied warranties, duties or conditions of merchantability, of fitness for a particular purpose, of reliability or availability, of accuracy or completeness of responses, of results, of workmanlike effort, of lack of viruses, and of lack of negligence."

Faced with such comprehensive denials that the software they buy will do anything useful, buyers turn to consumer protection agencies to place bounds on such evasion.

In fact, to the extent that software is a product and is provided with a written warranty at all, most of the disclaimers quoted above are simply inoperative in the United States under the Magnuson-Moss Warranty Act. State laws can also limit such disclaimers. (Those who advocate purchasing software as a service may be surprised to find that consumer protections for service transactions are often far weaker.)

Rather than paying lawyers to write long exclusion statements that state and federal laws can nullify, a development team may do much better to put a fraction of that effort into devising a warranty that actually means something.

Long overdue are specific statements as to the functions that a piece of software is intended to perform, the requirements that a customer must meet to keep that warranty in effect and the recourse that a customer will have in the event that this commitment is not met.

Full article...

Other Resource

... to read more articles, visit http://sqa.fyicenter.com/art/